Serial No. 09/934,582 

REMARKS 

INTRODUCTION 

Claims 1-26 were previously and are currently pending and under consideration. 

Claims 1-26 are rejected. 

Claims 1, 2, 7, and 24-26 are amended herein. 

No new matter is being presented, and approval and entry are respectfully requested. 

REJECTIONS UNDER 35 USC § 102 

In the Office Action, at pages 2-6, claims 1-26 were rejected under 35 U.S.C. § 102 as 
being anticipated by Hunkins. This rejection is traversed and reconsideration is requested. 

Claim 1 recites "updating a shared central subscriber directory used over a network by 
different autonomous telephony messaging systems to route subscriber messages", where 
subscriber information updated in the directory "becomes accessible by the messaging systems 
to route subscriber messages". Claim 7 recites "synchronizing a shared central subscriber 
directory server used over a network by different autonomous telephony voice messaging 
systems", and "updating the shared subscriber directory server ... whereby the updated 
subscriber information becomes accessible by the messaging systems to route subscriber 
messages". See also claims 24-26. 

The Hunkins reference discusses synchronizing common information among disparate 
databases, such as legacy databases of a telephony company. A user or administrator creates 
a change order, which is a "Project" containing changes, or "Change Objects". Referring to 
Figure 6 of Hunkins, a record is selected and copied 120, 121 from a common database. The 
user edits the copy of the record, and the edited copy is compared to the original record in the 
common database. The comparison is used to create a Change Object. Different Change 
Objects are added to make a Project. The user batch schedules the Project to execute at a 
future time, and when the time arrives, the Project is executed and its changes are mapped or 
formatted to different databases to which they are applied. In sum, Hunkins is a system to 
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broadcast a user's data changes to many databases, thus effecting data consistency among the 
databases despite their differences. 

Hunkins is primarily concerned with how a central change to data is applied to different 
databases. The databases that receive the changes are not plural different autonomous 
messaging systems, and they cannot use a central directory to route messages, with or without 
updates. The Hunkins system does not centralize distributed updates to a directory. Rather, 
Hunkins distributes centralized updates. 

Withdrawal of the rejection is respectfully requested. 

Claim 1 recites automatically updating when the update request is generated (which in 
turn is responsive to an actual database update having occurred). Claim 7 recites appending 
the update request to a queue "when the update request is generated", reading it from the 
queue and "updating the shared subscriber directory server in real-time". See also claims 24- 
26, which recite variations of updating when an update request is generated or responsive to a 
change to subscriber information. Claim 22 recites "updating the shared subscriber directory 
server in real-time based on the update request". 

Hunkins discloses only a user manually scheduling an update project. See item 144 in 
Figure 6. See also the portion of Hunkins at column 7, line 61 to column 8, line 9, which states 
that a 

"Change Object is ... placed in a batch file which is referred to as a 
Project. The user continues to edit records in this way generating 
Change Objects which are added to the user's Project. The user 
then completes the final change that makes up the logical set of 
changes ... The user now has an opportunity to review ... Once 
the user is happy [with the changes], he or she schedules the 
Project to be executed. This generally commits the changes to be 
distributed using the present invention. When the scheduled time 
is reached, the preferred embodiment begins processing each 
Change Object [in the scheduled Project]" 

Other portions of Hunkins relate the same manual batch scheduling process. Hunkins 

does not discuss or suggest an automated update process driven or actuated by changes in a 

database when they occur. Furthermore, such a modification would be unlikely, given that 

Hunkins explicitly aims to allow a user to review changes and carefully control the timing of their 

distribution. Furthermore, the changes in Hunkins are driven by a Project of changes, and the 
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changes go to all of the databases. This is different than taking a change in a database and 
updating a central directory in response. Hunkins is incompatible with real-time or change- 
driven updating. 

Withdrawal of the rejection of claims 1 , 7, 22, and 24-26 is further respectfully requested. 

Claims 22 recites "refreshing, with the update server, subscriber information in the 
update requests, after said reading and before said sending, in accordance with current 
corresponding subscriber information in the voice messaging system, when the update requests 
are one of expired and in a queue not primarily associated with the voice messaging system 
having the subscriber information". Claim 8 recites a similar feature. In Hunkins, once the 
user's Project is submitted and scheduled by the user, there are no further checks against the 
Common database. If there is a change in the Common database, that change will be 
overwritten when the Project is executed (or it will not be distributed to the other databases). 
Claims 22 and 8 are able to prevent a generated and queued change request itself from 
becoming stale or out unsynchronized. Hunkins does not discuss this kind of refreshing. 

Withdrawal of the rejection of claims 8 and 22 is respectfully requested. 

DEPENDENT CLAIMS 

The dependent claims are deemed patentable due at least to their dependence from 
allowable independent claims. These claims are also patentable due to their recitation of 
independently distinguishing features. For example, claim 2 recites "storing the update event at 
an intermediate server while maintaining synchronicity between the update event and the local 
messaging system". In Hunkins, synchronicity is not reliable and an intermediate server is not 
mentioned. Withdrawal of the rejection of the dependent claims is respectfully requested. 

CONCLUSION 

There being no further outstanding objections or rejections, it is submitted that the 
application is in condition for allowance. An early action to that effect is courteously solicited. 
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Finally, if there are any formal matters remaining after this response, the Examiner is 
requested to telephone the undersigned to attend to these matters. 

If there are any additional fees associated with filing of this Amendment, please charge 
the same to our Deposit Account No. 19-3935. 

Respectfully submitted, 

STAAS & HALSEY LLP 



Date: 
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1201 New York Avenue, NW, Suite 700 
Washington, D.C. 20005 
Telephone: (202) 434-1 500 
Facsimile: (202)434-1501 
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